You are viewing a plain text version of this content. The canonical link for it is here.
Posted to fop-users@xmlgraphics.apache.org by TomWilcox <wi...@hp.com> on 2009/07/10 18:51:41 UTC
Area Tree Handling
Hi,
First of all, I am a FOP dummy. I can make PDFs from FO but I don't know
about the inner workings.
I have FOP 0.95 embedded in my Java application. I would like to construct
an FO document and modify/examine the AreaTree for it on the fly.
This is in an attempt to fill blocks (of set size and position) on a page
with text/graphics and until the areatree info shows that block is full.
I would like to do this as fast as possible and I thought this would imply
the best route is to get hold of the areatree object in my application and
modify/access the objects of interest. (Or, failing that, to get hold area
tree xml fragments maybe)..
Can anyone tell me how I might go about achieving this?
Or even better, can anyone point me in the direction of any good
tutorials/examples that show Java code using embedded FOP to generate an
area tree object for an FO stream/file and then modify it with code..?
That would be awesome :)
Thanks in advance,
Tom
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: Area Tree Handling
Posted by Andreas Delmelle <an...@telenet.be>.
On 10 Jul 2009, at 18:51, TomWilcox wrote:
Hi Tom
> <snip />
> Or even better, can anyone point me in the direction of any good
> tutorials/examples that show Java code using embedded FOP to
> generate an
> area tree object for an FO stream/file and then modify it with code..?
Most examples of using FOP in an embedded fashion are available in the
repository, see:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/
Since you're planning on using the intermediate Area Tree XML, you may
want to check if you can use FOP Trunk and go for the new Intermediate
XML (which offers significant advantages over the Area Tree XML).
If you're stuck with 0.95 for the moment, no worries, the Area Tree
XML will still be supported.
Examples on using the Area Tree can be found here:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/atxml/
Examples on using the new IF, in the same base directory:
http://svn.apache.org/viewvc/xmlgraphics/fop/trunk/examples/embedding/java/embedding/intermediate/
IIC, then you may want to check if you can manipulate the Area Tree
XML by means of a stylesheet. That will facilitate writing the code,
since all you really need to do is insert an additional transformation
after producing the area tree.
The Area Tree XML format itself is undocumented, so you'll have to
study the output a bit before you will see how you can achieve the
desired result. If you run into questions, we'll be here to answer
them for you.
HTH, and Good luck!
Andreas
Andreas Delmelle
mailto:andreas.delmelle.AT.telenet.be
jabber: mandreas@jabber.org
skype: adlm0608
---
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: Area Tree Handling
Posted by Andreas Delmelle <an...@telenet.be>.
On 13 Jul 2009, at 12:06, TomWilcox wrote:
Hi Tom
> <snip />
> So I don't suppose anyone knows a way to handle, manipulate and re-
> render a
> fragment of the area tree using FOP?
As Georg already pointed out: it's either all or nothing. That said,
maybe it is possible in your environment to split up the source
document into multiple smaller ones, perform additional processing for
some, and concatenate all of them following the sample provided in the
repository.
Georg's sample code manipulates the area tree XML directly via Java
code, but as I suggested, this can also be done by running the area
tree through a second stylesheet transformation. The benefit is that
the additional Java code is kept to a minimum, and XSLT is really THE
weapon of choice when it comes to transforming XML.
HTH!
Regards,
Andreas
Andreas Delmelle
e-mail: andreas.delmelle.AT.telenet.be
Skype: adlm0608
Jabber: mandreas@jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Alright Jeremias I have created a page for the AT XML Documentation on the
FOP wiki:
http://wiki.apache.org/xmlgraphics-fop/AreaTreeXMLDocumentation
I have taken the liberty of adding a link to it on the main page to
encourage awareness..
Thanks for your help.
Tom
Jeremias Maerki-2 wrote:
>
> Tom, that's great, but why don't you just use our main Wiki?
> http://wiki.apache.org/xmlgraphics-fop/
>
> Another request: Please call this area tree XML rather than intermediate
> format. Yes, we called it that in the past but we have two intermediate
> formats now, so it's necessary to keep the two apart.
>
> On 25.08.2009 17:43:16 TomWilcox wrote:
>>
>> Hi Jeremias and Georg,
>>
>> Thanks very much. That's really helpful and at least good to know that no
>> proper documentation exists.
>>
>> I have taken the liberty of starting a wiki to share this information
>> whilst
>> I attempt to accumulate more info about the IF tree. If anyone would like
>> to
>> contribute please do. It would be great to produce something of use to
>> anyone else with similar needs.
>>
>> I have added the information that you have both provided me to the wiki
>> page
>> (and cited you both as contributors) please let me know if this is not OK
>> and feel free to edit.
>>
>> http://fop-if-tree.wikispaces.com/
>>
>> Thanks,
>> Tom
>>
>>
>>
>> Jeremias Maerki-2 wrote:
>> >
>> > There's no formal documentation of the area tree XML format to date. It
>> > is something very very few people need to use and the whole thing grew
>> > organically over time, so documentation wasn't a top priority. A
>> > contribution in this direction would be highly welcome. I'm happy to
>> > fill in any blanks if such a documentation is started. I don't have
>> time
>> > to write the whole thing myself in the short term.
>> >
>> > bpd = block-progression-dimension of the content rectangle of the area
>> > (= height for lr-tb script)
>> > bpda = allocated bpd = content bpd + spaces + borders + padding
>> >
>> > ipd = inline-progression-dimension of the content rectangle of the area
>> > (= width for lr-tb script)
>> > ipda = allocated ipd = content ipd + spaces + borders + padding
>> >
>> > Units are millipoints (1000ths of a point) as used in most of FOP (most
>> > notably the layout engine).
>> >
>> > Please note that our area tree is relatively close to the conceptual
>> > area tree (with its traits) described in the XSL specification. If you
>> > know a bit of the specification, the area tree XML is much easier to
>> > read.
>> >
>> > If you look into our layout engine test suite
>> > (test/layoutengine/standard-testcases), you'll find a lot of examples
>> of
>> > what is expected in the area tree for various situations.
>> >
>> > HTH
>> >
>> > On 25.08.2009 16:26:29 TomWilcox wrote:
>> >>
>> >> Hi Guys,
>> >>
>> >> Sorry to return your attention to this aging thread!
>> >>
>> >> I am knee deep in IF and I have a been attempting to divine what each
>> of
>> >> the
>> >> different node attributes represent such as bpd (block progression
>> >> dimension?), etc.
>> >>
>> >> It would be really good to have a definitive description of the
>> meaning
>> >> and
>> >> function of each of the attribute (and nodes) in an IF document. I
>> have
>> >> been
>> >> searching diligently however I have failed to find any document that
>> >> completely satisfies this requirement.
>> >>
>> >> Would be possible for you provide me with a link to a thorough
>> >> documentation
>> >> of the IF format or, if not, perhaps you might be able to provide an
>> >> explanation of the attributes important for reading the dimension of a
>> >> given
>> >> block from an IF document (I think position is bpd, ipd, .. but ipda?
>> and
>> >> bpda?) and what are the units (millipoints?).
>> >>
>> >> I am very grateful for any assistance.
>> >>
>> >> Thanks in advance,
>> >> Tom
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
>> >> Sent from the FOP - Users mailing list archive at Nabble.com.
>> >
>> >
>> > Jeremias Maerki
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p25136891.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25137549.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
OK Can do..
Jeremias Maerki-2 wrote:
>
> Tom, that's great, but why don't you just use our main Wiki?
> http://wiki.apache.org/xmlgraphics-fop/
>
> Another request: Please call this area tree XML rather than intermediate
> format. Yes, we called it that in the past but we have two intermediate
> formats now, so it's necessary to keep the two apart.
>
> On 25.08.2009 17:43:16 TomWilcox wrote:
>>
>> Hi Jeremias and Georg,
>>
>> Thanks very much. That's really helpful and at least good to know that no
>> proper documentation exists.
>>
>> I have taken the liberty of starting a wiki to share this information
>> whilst
>> I attempt to accumulate more info about the IF tree. If anyone would like
>> to
>> contribute please do. It would be great to produce something of use to
>> anyone else with similar needs.
>>
>> I have added the information that you have both provided me to the wiki
>> page
>> (and cited you both as contributors) please let me know if this is not OK
>> and feel free to edit.
>>
>> http://fop-if-tree.wikispaces.com/
>>
>> Thanks,
>> Tom
>>
>>
>>
>> Jeremias Maerki-2 wrote:
>> >
>> > There's no formal documentation of the area tree XML format to date. It
>> > is something very very few people need to use and the whole thing grew
>> > organically over time, so documentation wasn't a top priority. A
>> > contribution in this direction would be highly welcome. I'm happy to
>> > fill in any blanks if such a documentation is started. I don't have
>> time
>> > to write the whole thing myself in the short term.
>> >
>> > bpd = block-progression-dimension of the content rectangle of the area
>> > (= height for lr-tb script)
>> > bpda = allocated bpd = content bpd + spaces + borders + padding
>> >
>> > ipd = inline-progression-dimension of the content rectangle of the area
>> > (= width for lr-tb script)
>> > ipda = allocated ipd = content ipd + spaces + borders + padding
>> >
>> > Units are millipoints (1000ths of a point) as used in most of FOP (most
>> > notably the layout engine).
>> >
>> > Please note that our area tree is relatively close to the conceptual
>> > area tree (with its traits) described in the XSL specification. If you
>> > know a bit of the specification, the area tree XML is much easier to
>> > read.
>> >
>> > If you look into our layout engine test suite
>> > (test/layoutengine/standard-testcases), you'll find a lot of examples
>> of
>> > what is expected in the area tree for various situations.
>> >
>> > HTH
>> >
>> > On 25.08.2009 16:26:29 TomWilcox wrote:
>> >>
>> >> Hi Guys,
>> >>
>> >> Sorry to return your attention to this aging thread!
>> >>
>> >> I am knee deep in IF and I have a been attempting to divine what each
>> of
>> >> the
>> >> different node attributes represent such as bpd (block progression
>> >> dimension?), etc.
>> >>
>> >> It would be really good to have a definitive description of the
>> meaning
>> >> and
>> >> function of each of the attribute (and nodes) in an IF document. I
>> have
>> >> been
>> >> searching diligently however I have failed to find any document that
>> >> completely satisfies this requirement.
>> >>
>> >> Would be possible for you provide me with a link to a thorough
>> >> documentation
>> >> of the IF format or, if not, perhaps you might be able to provide an
>> >> explanation of the attributes important for reading the dimension of a
>> >> given
>> >> block from an IF document (I think position is bpd, ipd, .. but ipda?
>> and
>> >> bpda?) and what are the units (millipoints?).
>> >>
>> >> I am very grateful for any assistance.
>> >>
>> >> Thanks in advance,
>> >> Tom
>> >> --
>> >> View this message in context:
>> >> http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
>> >> Sent from the FOP - Users mailing list archive at Nabble.com.
>> >
>> >
>> > Jeremias Maerki
>> >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
>> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>> >
>> >
>> >
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p25136891.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25137081.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
Tom, that's great, but why don't you just use our main Wiki?
http://wiki.apache.org/xmlgraphics-fop/
Another request: Please call this area tree XML rather than intermediate
format. Yes, we called it that in the past but we have two intermediate
formats now, so it's necessary to keep the two apart.
On 25.08.2009 17:43:16 TomWilcox wrote:
>
> Hi Jeremias and Georg,
>
> Thanks very much. That's really helpful and at least good to know that no
> proper documentation exists.
>
> I have taken the liberty of starting a wiki to share this information whilst
> I attempt to accumulate more info about the IF tree. If anyone would like to
> contribute please do. It would be great to produce something of use to
> anyone else with similar needs.
>
> I have added the information that you have both provided me to the wiki page
> (and cited you both as contributors) please let me know if this is not OK
> and feel free to edit.
>
> http://fop-if-tree.wikispaces.com/
>
> Thanks,
> Tom
>
>
>
> Jeremias Maerki-2 wrote:
> >
> > There's no formal documentation of the area tree XML format to date. It
> > is something very very few people need to use and the whole thing grew
> > organically over time, so documentation wasn't a top priority. A
> > contribution in this direction would be highly welcome. I'm happy to
> > fill in any blanks if such a documentation is started. I don't have time
> > to write the whole thing myself in the short term.
> >
> > bpd = block-progression-dimension of the content rectangle of the area
> > (= height for lr-tb script)
> > bpda = allocated bpd = content bpd + spaces + borders + padding
> >
> > ipd = inline-progression-dimension of the content rectangle of the area
> > (= width for lr-tb script)
> > ipda = allocated ipd = content ipd + spaces + borders + padding
> >
> > Units are millipoints (1000ths of a point) as used in most of FOP (most
> > notably the layout engine).
> >
> > Please note that our area tree is relatively close to the conceptual
> > area tree (with its traits) described in the XSL specification. If you
> > know a bit of the specification, the area tree XML is much easier to
> > read.
> >
> > If you look into our layout engine test suite
> > (test/layoutengine/standard-testcases), you'll find a lot of examples of
> > what is expected in the area tree for various situations.
> >
> > HTH
> >
> > On 25.08.2009 16:26:29 TomWilcox wrote:
> >>
> >> Hi Guys,
> >>
> >> Sorry to return your attention to this aging thread!
> >>
> >> I am knee deep in IF and I have a been attempting to divine what each of
> >> the
> >> different node attributes represent such as bpd (block progression
> >> dimension?), etc.
> >>
> >> It would be really good to have a definitive description of the meaning
> >> and
> >> function of each of the attribute (and nodes) in an IF document. I have
> >> been
> >> searching diligently however I have failed to find any document that
> >> completely satisfies this requirement.
> >>
> >> Would be possible for you provide me with a link to a thorough
> >> documentation
> >> of the IF format or, if not, perhaps you might be able to provide an
> >> explanation of the attributes important for reading the dimension of a
> >> given
> >> block from an IF document (I think position is bpd, ipd, .. but ipda? and
> >> bpda?) and what are the units (millipoints?).
> >>
> >> I am very grateful for any assistance.
> >>
> >> Thanks in advance,
> >> Tom
> >> --
> >> View this message in context:
> >> http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
> >> Sent from the FOP - Users mailing list archive at Nabble.com.
> >
> >
> > Jeremias Maerki
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> > For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25136891.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Hi Jeremias and Georg,
Thanks very much. That's really helpful and at least good to know that no
proper documentation exists.
I have taken the liberty of starting a wiki to share this information whilst
I attempt to accumulate more info about the IF tree. If anyone would like to
contribute please do. It would be great to produce something of use to
anyone else with similar needs.
I have added the information that you have both provided me to the wiki page
(and cited you both as contributors) please let me know if this is not OK
and feel free to edit.
http://fop-if-tree.wikispaces.com/
Thanks,
Tom
Jeremias Maerki-2 wrote:
>
> There's no formal documentation of the area tree XML format to date. It
> is something very very few people need to use and the whole thing grew
> organically over time, so documentation wasn't a top priority. A
> contribution in this direction would be highly welcome. I'm happy to
> fill in any blanks if such a documentation is started. I don't have time
> to write the whole thing myself in the short term.
>
> bpd = block-progression-dimension of the content rectangle of the area
> (= height for lr-tb script)
> bpda = allocated bpd = content bpd + spaces + borders + padding
>
> ipd = inline-progression-dimension of the content rectangle of the area
> (= width for lr-tb script)
> ipda = allocated ipd = content ipd + spaces + borders + padding
>
> Units are millipoints (1000ths of a point) as used in most of FOP (most
> notably the layout engine).
>
> Please note that our area tree is relatively close to the conceptual
> area tree (with its traits) described in the XSL specification. If you
> know a bit of the specification, the area tree XML is much easier to
> read.
>
> If you look into our layout engine test suite
> (test/layoutengine/standard-testcases), you'll find a lot of examples of
> what is expected in the area tree for various situations.
>
> HTH
>
> On 25.08.2009 16:26:29 TomWilcox wrote:
>>
>> Hi Guys,
>>
>> Sorry to return your attention to this aging thread!
>>
>> I am knee deep in IF and I have a been attempting to divine what each of
>> the
>> different node attributes represent such as bpd (block progression
>> dimension?), etc.
>>
>> It would be really good to have a definitive description of the meaning
>> and
>> function of each of the attribute (and nodes) in an IF document. I have
>> been
>> searching diligently however I have failed to find any document that
>> completely satisfies this requirement.
>>
>> Would be possible for you provide me with a link to a thorough
>> documentation
>> of the IF format or, if not, perhaps you might be able to provide an
>> explanation of the attributes important for reading the dimension of a
>> given
>> block from an IF document (I think position is bpd, ipd, .. but ipda? and
>> bpda?) and what are the units (millipoints?).
>>
>> I am very grateful for any assistance.
>>
>> Thanks in advance,
>> Tom
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25136891.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Hi Jeremias and Georg,
Thanks very much. That's really helpful and at least good to know that no
proper documentation exists.
I have taken the liberty of starting a wiki to share this information whilst
I attempt to accumulate more info about the IF tree. If anyone would like to
contribute please do. It would be great to produce something of use to
anyone else with similar needs.
I have added the information that you have both provided me to the wiki page
(and cited you both as contributors) please let me know if this is not OK
and feel free to edit.
Thanks,
Tom
Jeremias Maerki-2 wrote:
>
> There's no formal documentation of the area tree XML format to date. It
> is something very very few people need to use and the whole thing grew
> organically over time, so documentation wasn't a top priority. A
> contribution in this direction would be highly welcome. I'm happy to
> fill in any blanks if such a documentation is started. I don't have time
> to write the whole thing myself in the short term.
>
> bpd = block-progression-dimension of the content rectangle of the area
> (= height for lr-tb script)
> bpda = allocated bpd = content bpd + spaces + borders + padding
>
> ipd = inline-progression-dimension of the content rectangle of the area
> (= width for lr-tb script)
> ipda = allocated ipd = content ipd + spaces + borders + padding
>
> Units are millipoints (1000ths of a point) as used in most of FOP (most
> notably the layout engine).
>
> Please note that our area tree is relatively close to the conceptual
> area tree (with its traits) described in the XSL specification. If you
> know a bit of the specification, the area tree XML is much easier to
> read.
>
> If you look into our layout engine test suite
> (test/layoutengine/standard-testcases), you'll find a lot of examples of
> what is expected in the area tree for various situations.
>
> HTH
>
> On 25.08.2009 16:26:29 TomWilcox wrote:
>>
>> Hi Guys,
>>
>> Sorry to return your attention to this aging thread!
>>
>> I am knee deep in IF and I have a been attempting to divine what each of
>> the
>> different node attributes represent such as bpd (block progression
>> dimension?), etc.
>>
>> It would be really good to have a definitive description of the meaning
>> and
>> function of each of the attribute (and nodes) in an IF document. I have
>> been
>> searching diligently however I have failed to find any document that
>> completely satisfies this requirement.
>>
>> Would be possible for you provide me with a link to a thorough
>> documentation
>> of the IF format or, if not, perhaps you might be able to provide an
>> explanation of the attributes important for reading the dimension of a
>> given
>> block from an IF document (I think position is bpd, ipd, .. but ipda? and
>> bpda?) and what are the units (millipoints?).
>>
>> I am very grateful for any assistance.
>>
>> Thanks in advance,
>> Tom
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> Jeremias Maerki
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
> For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25136874.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
There's no formal documentation of the area tree XML format to date. It
is something very very few people need to use and the whole thing grew
organically over time, so documentation wasn't a top priority. A
contribution in this direction would be highly welcome. I'm happy to
fill in any blanks if such a documentation is started. I don't have time
to write the whole thing myself in the short term.
bpd = block-progression-dimension of the content rectangle of the area
(= height for lr-tb script)
bpda = allocated bpd = content bpd + spaces + borders + padding
ipd = inline-progression-dimension of the content rectangle of the area
(= width for lr-tb script)
ipda = allocated ipd = content ipd + spaces + borders + padding
Units are millipoints (1000ths of a point) as used in most of FOP (most
notably the layout engine).
Please note that our area tree is relatively close to the conceptual
area tree (with its traits) described in the XSL specification. If you
know a bit of the specification, the area tree XML is much easier to
read.
If you look into our layout engine test suite
(test/layoutengine/standard-testcases), you'll find a lot of examples of
what is expected in the area tree for various situations.
HTH
On 25.08.2009 16:26:29 TomWilcox wrote:
>
> Hi Guys,
>
> Sorry to return your attention to this aging thread!
>
> I am knee deep in IF and I have a been attempting to divine what each of the
> different node attributes represent such as bpd (block progression
> dimension?), etc.
>
> It would be really good to have a definitive description of the meaning and
> function of each of the attribute (and nodes) in an IF document. I have been
> searching diligently however I have failed to find any document that
> completely satisfies this requirement.
>
> Would be possible for you provide me with a link to a thorough documentation
> of the IF format or, if not, perhaps you might be able to provide an
> explanation of the attributes important for reading the dimension of a given
> block from an IF document (I think position is bpd, ipd, .. but ipda? and
> bpda?) and what are the units (millipoints?).
>
> I am very grateful for any assistance.
>
> Thanks in advance,
> Tom
> --
> View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: AW: AW: AW: AW: Area Tree Handling
Posted by Georg Datterl <ge...@geneon.de>.
Hi Tom,
bpd is the HEIGHT of the area. prod-id is the reference attribute id. Those are the ones I use extensively.
Mit freundlichen Grüßen
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: TomWilcox [mailto:wilcox@hp.com]
Gesendet: Dienstag, 25. August 2009 16:26
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: AW: AW: AW: AW: Area Tree Handling
Hi Guys,
Sorry to return your attention to this aging thread!
I am knee deep in IF and I have a been attempting to divine what each of the different node attributes represent such as bpd (block progression dimension?), etc.
It would be really good to have a definitive description of the meaning and function of each of the attribute (and nodes) in an IF document. I have been searching diligently however I have failed to find any document that completely satisfies this requirement.
Would be possible for you provide me with a link to a thorough documentation of the IF format or, if not, perhaps you might be able to provide an explanation of the attributes important for reading the dimension of a given block from an IF document (I think position is bpd, ipd, .. but ipda? and
bpda?) and what are the units (millipoints?).
I am very grateful for any assistance.
Thanks in advance,
Tom
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Hi Guys,
Sorry to return your attention to this aging thread!
I am knee deep in IF and I have a been attempting to divine what each of the
different node attributes represent such as bpd (block progression
dimension?), etc.
It would be really good to have a definitive description of the meaning and
function of each of the attribute (and nodes) in an IF document. I have been
searching diligently however I have failed to find any document that
completely satisfies this requirement.
Would be possible for you provide me with a link to a thorough documentation
of the IF format or, if not, perhaps you might be able to provide an
explanation of the attributes important for reading the dimension of a given
block from an IF document (I think position is bpd, ipd, .. but ipda? and
bpda?) and what are the units (millipoints?).
I am very grateful for any assistance.
Thanks in advance,
Tom
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25135373.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
Posted by Andreas Delmelle <an...@telenet.be>.
On 14 Jul 2009, at 17:31, Georg Datterl wrote:
>> Well, it is only available in the SVN repo, so in the sense that it
>> is not
>> officially released yet, it is indeed in development. That said,
>> some users
>> consider trunk to be stable enough to use in production environments.
>
> As far as I understood, out-of-the-ant-file Fop still uses AT, not
> IF, as default rendering path.
I'd have to check to be certain, but in Trunk, I seem to recall that
we ultimately opted for using the IF-route out of the box (since it
proved a tiny bit faster). The testsuite still uses the Area Tree
(hence why it will probably remain for a while; someone would have to
convert all existing testcases... :-/)
> But that reminds me, I wanted to find out how to activate IF and
> see, what happens to my publications.
>
>> The benefits of the new IF are mainly: <...> it is better
>> documented than the Area Tree.
>
> Well, that ain't hard. :-)
Indeed... :-)
Andreas Delmelle
e-mail: andreas.delmelle.AT.telenet.be
Skype: adlm0608
Jabber: mandreas@jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: AW: AW: AW: Area Tree Handling
Posted by Georg Datterl <ge...@geneon.de>.
Hi Tom, Andreas,
> Well, it is only available in the SVN repo, so in the sense that it is not
> officially released yet, it is indeed in development. That said, some users
> consider trunk to be stable enough to use in production environments.
As far as I understood, out-of-the-ant-file Fop still uses AT, not IF, as default rendering path. But that reminds me, I wanted to find out how to activate IF and see, what happens to my publications.
> The benefits of the new IF are mainly: <...> it is better documented than the Area Tree.
Well, that ain't hard. :-)
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: Andreas Delmelle [mailto:andreas.delmelle@telenet.be]
Gesendet: Dienstag, 14. Juli 2009 17:17
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: AW: AW: AW: Area Tree Handling
On 14 Jul 2009, at 16:43, TomWilcox wrote:
Hi Tom, Georg,
> I look forward to getting into the IF however I was under the
> impression it is still very much in the development phase..
Well, it is only available in the SVN repo, so in the sense that it is not officially released yet, it is indeed in development. That said, some users consider trunk to be stable enough to use in production environments.
The benefits of the new IF are mainly: optimized parsing (faster) and it is better documented than the Area Tree. The Area Tree XML will probably remain alive for some time. In some use-cases, the new IF could lack some of the more detailed structure information that is preserved in the Area Tree.
It's really up to you, but we encourage to use the newer IF, since that is ultimately one sure way of getting feedback based on real-life scenarios. All we know for a fact is that our test-suite does not fail, but that is no guarantee whatsoever that everything is A-OK.
>> However, I would like to propose a potentially useful future feature
>> of FOP would be the ability to do this using Java objects with a view
>> for optimising modifications of document fragments such as a subtree
>> of the AT through an API (as I think either yourself or Andreas
>> mentioned earlier).
IIC, the reason we opted for XML formats in the first place, is that one does not really need a specialized API to perform such manipulations. Why double the effort if XSLT already provides you with basically everything you need?
All you'd need to do is write some stylesheet code to modify/ manipulate either the Area Tree XML or the IF, and use the standard JAXP pattern to apply the stylesheet to the intermediate XML. That is basically the same pattern that you already use to feed the input to FOP...
>> Any ideas where I post suggestions for FOP features?
A Bugzilla entry would be a start, but do mind the above reservations.
I would be reluctant to introduce such a feature (and thus increase our maintenance overhead), for something that is fairly straightforward to achieve using standard JAXP and XSLT (requiring no changes to the FOP codebase, and still offering all the flexibility that one could desire, IMO)
Regards
Andreas
Andreas Delmelle
e-mail: andreas.delmelle.AT.telenet.be
Skype: adlm0608
Jabber: mandreas@jabber.org
---------------------------------------------------------------------
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
Re: AW: AW: AW: AW: Area Tree Handling
Posted by Andreas Delmelle <an...@telenet.be>.
On 14 Jul 2009, at 16:43, TomWilcox wrote:
Hi Tom, Georg,
> I look forward to getting into the IF however I was under the
> impression it
> is still very much in the development phase..
Well, it is only available in the SVN repo, so in the sense that it is
not officially released yet, it is indeed in development. That said,
some users consider trunk to be stable enough to use in production
environments.
The benefits of the new IF are mainly: optimized parsing (faster) and
it is better documented than the Area Tree. The Area Tree XML will
probably remain alive for some time. In some use-cases, the new IF
could lack some of the more detailed structure information that is
preserved in the Area Tree.
It's really up to you, but we encourage to use the newer IF, since
that is ultimately one sure way of getting feedback based on real-life
scenarios. All we know for a fact is that our test-suite does not
fail, but that is no guarantee whatsoever that everything is A-OK.
>> However, I would like to propose a potentially useful future
>> feature of
>> FOP would be the ability to do this using Java objects with a view
>> for
>> optimising modifications of document fragments such as a subtree of
>> the AT
>> through an API (as I think either yourself or Andreas mentioned
>> earlier).
IIC, the reason we opted for XML formats in the first place, is that
one does not really need a specialized API to perform such
manipulations. Why double the effort if XSLT already provides you with
basically everything you need?
All you'd need to do is write some stylesheet code to modify/
manipulate either the Area Tree XML or the IF, and use the standard
JAXP pattern to apply the stylesheet to the intermediate XML. That is
basically the same pattern that you already use to feed the input to
FOP...
>> Any ideas where I post suggestions for FOP features?
A Bugzilla entry would be a start, but do mind the above reservations.
I would be reluctant to introduce such a feature (and thus increase
our maintenance overhead), for something that is fairly
straightforward to achieve using standard JAXP and XSLT (requiring no
changes to the FOP codebase, and still offering all the flexibility
that one could desire, IMO)
Regards
Andreas
Andreas Delmelle
e-mail: andreas.delmelle.AT.telenet.be
Skype: adlm0608
Jabber: mandreas@jabber.org
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Cheers Georg,
I look forward to getting into the IF however I was under the impression it
is still very much in the development phase..
Geord Datterl wrote:
>
> What I did and what might help you too: I need to build a FO file (no
> transformation), so I built wrappers around the different FO constructs,
> set the attributes through getter and setter methods and build the FO file
> in memory. Then I can change any attribute by a simple method call, as
> long as I still have a reference to the interesting Block object. When I'm
> satisfied, a toString call to the root element generates the complete FO
> file.
>
I do have something similar to that which I think can be modified to do the
job.
Thanks,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> First, AT ist going out of style, as far as I understood. The new
> IntermediateFormat will replace it. Second, I don't see how an API would
> help you. Of course, you can modify the AT objects and for example, add
> text. But to get a meaningfull result, the whole breaking/layouting, which
> results in the AT, would have to be redone, so Fop would have to accept
> your changes, revert them to FO, then layout again. It's by far easier and
> safer, if you make your changes in the FO file and then layout again. Or
> Fop would need an AT-to-AT converter, which doesn't sound quite possible
> to me.
>
> What I did and what might help you too: I need to build a FO file (no
> transformation), so I built wrappers around the different FO constructs,
> set the attributes through getter and setter methods and build the FO file
> in memory. Then I can change any attribute by a simple method call, as
> long as I still have a reference to the interesting Block object. When I'm
> satisfied, a toString call to the root element generates the complete FO
> file.
>
> Mit freundlichen Grüßen
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Dienstag, 14. Juli 2009 15:16
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: AW: AW: Area Tree Handling
>
>
> Thanks Georg,
>
> That seems like the approach for me :).
>
> However, I would like to propose a potentially useful future feature of
> FOP would be the ability to do this using Java objects with a view for
> optimising modifications of document fragments such as a subtree of the AT
> through an API (as I think either yourself or Andreas mentioned earlier).
> Any ideas where I post suggestions for FOP features?
>
> Cheers,
> Tom
>
>
> Georg Datterl wrote:
>>
>> Hi Tom,
>>
>> In that case I'd take the interesting fo block, wrap it with a default
>> page and render it. Of course the page is overhead, but other than
>> that you only render the interesting block. When you are satisfied
>> with it, continue with the next block. Only when all blocks are
>> finished, combine them to a document. Of course, this does not work,
>> when you have to think about page breaks. I have a similar problem
>> with tables and cell content which has to be duplicated on the next
>> page, if there's a break. In the end, I generate the whole stuff over
>> and over again, because each table has to know exactly where on the
>> page it starts. Horrible. But customer wants it that way, so what can I
>> do?
>>
>> Regards,
>>
>> Georg Datterl
>>
>> ------ Kontakt ------
>>
>> Georg Datterl
>>
>> Geneon media solutions gmbh
>> Gutenstetter Straße 8a
>> 90449 Nürnberg
>>
>> HRB Nürnberg: 17193
>> Geschäftsführer: Yong-Harry Steiert
>>
>> Tel.: 0911/36 78 88 - 26
>> Fax: 0911/36 78 88 - 20
>>
>> www.geneon.de
>>
>> Weitere Mitglieder der Willmy MediaGroup:
>>
>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>> Willmy PrintMedia GmbH: www.willmy.de
>> Willmy Consult & Content GmbH: www.willmycc.de
>> -----Ursprüngliche Nachricht-----
>> Von: TomWilcox [mailto:wilcox@hp.com]
>> Gesendet: Montag, 13. Juli 2009 16:30
>> An: fop-users@xmlgraphics.apache.org
>> Betreff: Re: AW: AW: Area Tree Handling
>>
>>
>> Georg,
>>
>> Sorry I think I have explained this badly (or completely wrong)...
>>
>> I am trying to take some FO, render the AT, then look at
>> fragments/nodes of the AT, then modify the FO related to that fragment
>> and regenerate the AT for that fragment. Then reevaluate the AT and if
>> my criterion are satisfied, I will render a PDF from the AT.
>>
>> What I am trying to do is take some text/image content and fill blocks
>> of set size and position. At the moment I have a guess at how much
>> space the text and images take up in the block and then output FO
>> which is converted into a PDF. This produces page layouts with heavy
>> over/underflow..
>>
>> I am constrained to use blocks of a set size and position, there I
>> would like to know if I can access an intermediate format that gives
>> me the amount of space left in the block and would allow me to add
>> more text/images in order to fill the block.
>>
>> Cheers,
>> Tom
>>
>>
>> Georg Datterl wrote:
>>>
>>> Hi Tom,
>>>
>>> I'm not quite sure I understand what you want to do. You are
>>> rendering FO to AT, manipulate the AT and then generate a PDF. I
>>> don't think you can render the PDF, then manipulate the AT and
>>> rerender the changed nodes into the previously generated PDF. You can
>>> of course generate the AT, then manipulate it, then generate the PDF
>>> based on the manipulated AT.
>>>
>>> Regards,
>>>
>>> Georg Datterl
>>>
>>> ------ Kontakt ------
>>>
>>> Georg Datterl
>>>
>>> Geneon media solutions gmbh
>>> Gutenstetter Straße 8a
>>> 90449 Nürnberg
>>>
>>> HRB Nürnberg: 17193
>>> Geschäftsführer: Yong-Harry Steiert
>>>
>>> Tel.: 0911/36 78 88 - 26
>>> Fax: 0911/36 78 88 - 20
>>>
>>> www.geneon.de
>>>
>>> Weitere Mitglieder der Willmy MediaGroup:
>>>
>>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>>> Willmy PrintMedia GmbH: www.willmy.de
>>> Willmy Consult & Content GmbH: www.willmycc.de
>>> -----Ursprüngliche Nachricht-----
>>> Von: TomWilcox [mailto:wilcox@hp.com]
>>> Gesendet: Montag, 13. Juli 2009 12:06
>>> An: fop-users@xmlgraphics.apache.org
>>> Betreff: Re: AW: Area Tree Handling
>>>
>>>
>>> Thanks Georg,
>>>
>>> That's great. I was doing something a bit similar however I did not
>>> use the sax result to get a node of the DOM tree and traverse using
>>> XPath.
>>>
>>> I am not sure this will be efficient enough for me as I need to
>>> traverse, modify and then render various nodes repeatedly in a very
>>> short space of time. I was keen to find a method that would allow me
>>> to alter and reevaluate a fragment of the area tree (rerendering that
>>> part of the AT using FOP without wasting time, rendering the rest).
>>>
>>> So I don't suppose anyone knows a way to handle, manipulate and
>>> re-render a fragment of the area tree using FOP?
>>>
>>> I will keep experimenting in the meantime!
>>>
>>> Cheers,
>>> Tom
>>>
>>>
>>>
>>>
>>>
>>> Georg Datterl wrote:
>>>>
>>>> Hi Tom,
>>>>
>>>> I get the area tree using
>>>>
>>>> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
>>>> Transformer transformer =
>>>> getMultipassFactory().newTransformer();
>>>> TransformerHandler handler =
>>>> getMultipassFactory().newTransformerHandler();
>>>> DOMResult domResult = new DOMResult();
>>>> handler.setResult(domResult);
>>>>
>>>> org.apache.fop.render.Renderer targetRenderer =
>>>> foUserAgent.getRendererFactory().createRenderer(
>>>> foUserAgent, MimeConstants.MIME_PDF);
>>>>
>>>> XMLRenderer renderer = new XMLRenderer();
>>>> renderer.mimicRenderer(targetRenderer);
>>>> renderer.setContentHandler(handler);
>>>> renderer.setUserAgent(foUserAgent);
>>>>
>>>> foUserAgent.setRendererOverride(renderer);
>>>>
>>>> Fop fop =
>>>> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
>>>> Result res = new SAXResult(fop.getDefaultHandler());
>>>> transformer.transform(source, res);
>>>> org.w3c.dom.Document doc = domResult.getNode();
>>>>
>>>> Then I get values from the tree through Xpath
>>>>
>>>> XPathFactory factory=XPathFactory.newInstance();
>>>> XPath xPath=factory.newXPath();
>>>> NodeList nl =
>>>> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
>>>> XPathConstants.NODESET);
>>>> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
>>>> nl.item(i),
>>>> XPathConstants.NUMBER)
>>>>
>>>> The blocks I'm interested in have well-known ids and I'm interested
>>>> in more than one information below the node with id DT_TAGxx, that's
>>>> why I use a nodelist. When you find a smarter way to get the
>>>> information, please tell me, cause this xpath solution is not very
>>>> fast in large documents...
>>>>
>>>> Regards,
>>>>
>>>> Georg Datterl
>>>>
>>>> ------ Kontakt ------
>>>>
>>>> Georg Datterl
>>>>
>>>> Geneon media solutions gmbh
>>>> Gutenstetter Straße 8a
>>>> 90449 Nürnberg
>>>>
>>>> HRB Nürnberg: 17193
>>>> Geschäftsführer: Yong-Harry Steiert
>>>>
>>>> Tel.: 0911/36 78 88 - 26
>>>> Fax: 0911/36 78 88 - 20
>>>>
>>>> www.geneon.de
>>>>
>>>> Weitere Mitglieder der Willmy MediaGroup:
>>>>
>>>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>>>> Willmy PrintMedia GmbH: www.willmy.de
>>>> Willmy Consult & Content GmbH: www.willmycc.de
>>>> -----Ursprüngliche Nachricht-----
>>>> Von: TomWilcox [mailto:wilcox@hp.com]
>>>> Gesendet: Freitag, 10. Juli 2009 18:52
>>>> An: fop-users@xmlgraphics.apache.org
>>>> Betreff: Area Tree Handling
>>>>
>>>>
>>>> Hi,
>>>>
>>>> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
>>>> know about the inner workings.
>>>>
>>>> I have FOP 0.95 embedded in my Java application. I would like to
>>>> construct an FO document and modify/examine the AreaTree for it on
>>>> the fly.
>>>>
>>>> This is in an attempt to fill blocks (of set size and position) on a
>>>> page with text/graphics and until the areatree info shows that block
>>>> is full.
>>>>
>>>> I would like to do this as fast as possible and I thought this would
>>>> imply the best route is to get hold of the areatree object in my
>>>> application and modify/access the objects of interest. (Or, failing
>>>> that, to get hold area tree xml fragments maybe)..
>>>>
>>>> Can anyone tell me how I might go about achieving this?
>>>>
>>>> Or even better, can anyone point me in the direction of any good
>>>> tutorials/examples that show Java code using embedded FOP to
>>>> generate an area tree object for an FO stream/file and then modify
>>>> it with code..?
>>>>
>>>> That would be awesome :)
>>>>
>>>> Thanks in advance,
>>>> Tom
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
>>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>> --------------------------------------------------------------------
>>>> - 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
>>>>
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24462824.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24479220.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24481019.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: AW: AW: Area Tree Handling
Posted by Georg Datterl <ge...@geneon.de>.
Hi Tom,
First, AT ist going out of style, as far as I understood. The new IntermediateFormat will replace it. Second, I don't see how an API would help you. Of course, you can modify the AT objects and for example, add text. But to get a meaningfull result, the whole breaking/layouting, which results in the AT, would have to be redone, so Fop would have to accept your changes, revert them to FO, then layout again. It's by far easier and safer, if you make your changes in the FO file and then layout again. Or Fop would need an AT-to-AT converter, which doesn't sound quite possible to me.
What I did and what might help you too: I need to build a FO file (no transformation), so I built wrappers around the different FO constructs, set the attributes through getter and setter methods and build the FO file in memory. Then I can change any attribute by a simple method call, as long as I still have a reference to the interesting Block object. When I'm satisfied, a toString call to the root element generates the complete FO file.
Mit freundlichen Grüßen
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: TomWilcox [mailto:wilcox@hp.com]
Gesendet: Dienstag, 14. Juli 2009 15:16
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: AW: AW: Area Tree Handling
Thanks Georg,
That seems like the approach for me :).
However, I would like to propose a potentially useful future feature of FOP would be the ability to do this using Java objects with a view for optimising modifications of document fragments such as a subtree of the AT through an API (as I think either yourself or Andreas mentioned earlier).
Any ideas where I post suggestions for FOP features?
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> In that case I'd take the interesting fo block, wrap it with a default
> page and render it. Of course the page is overhead, but other than
> that you only render the interesting block. When you are satisfied
> with it, continue with the next block. Only when all blocks are
> finished, combine them to a document. Of course, this does not work,
> when you have to think about page breaks. I have a similar problem
> with tables and cell content which has to be duplicated on the next
> page, if there's a break. In the end, I generate the whole stuff over
> and over again, because each table has to know exactly where on the
> page it starts. Horrible. But customer wants it that way, so what can I do?
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Montag, 13. Juli 2009 16:30
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: AW: Area Tree Handling
>
>
> Georg,
>
> Sorry I think I have explained this badly (or completely wrong)...
>
> I am trying to take some FO, render the AT, then look at
> fragments/nodes of the AT, then modify the FO related to that fragment
> and regenerate the AT for that fragment. Then reevaluate the AT and if
> my criterion are satisfied, I will render a PDF from the AT.
>
> What I am trying to do is take some text/image content and fill blocks
> of set size and position. At the moment I have a guess at how much
> space the text and images take up in the block and then output FO
> which is converted into a PDF. This produces page layouts with heavy over/underflow..
>
> I am constrained to use blocks of a set size and position, there I
> would like to know if I can access an intermediate format that gives
> me the amount of space left in the block and would allow me to add
> more text/images in order to fill the block.
>
> Cheers,
> Tom
>
>
> Georg Datterl wrote:
>>
>> Hi Tom,
>>
>> I'm not quite sure I understand what you want to do. You are
>> rendering FO to AT, manipulate the AT and then generate a PDF. I
>> don't think you can render the PDF, then manipulate the AT and
>> rerender the changed nodes into the previously generated PDF. You can
>> of course generate the AT, then manipulate it, then generate the PDF
>> based on the manipulated AT.
>>
>> Regards,
>>
>> Georg Datterl
>>
>> ------ Kontakt ------
>>
>> Georg Datterl
>>
>> Geneon media solutions gmbh
>> Gutenstetter Straße 8a
>> 90449 Nürnberg
>>
>> HRB Nürnberg: 17193
>> Geschäftsführer: Yong-Harry Steiert
>>
>> Tel.: 0911/36 78 88 - 26
>> Fax: 0911/36 78 88 - 20
>>
>> www.geneon.de
>>
>> Weitere Mitglieder der Willmy MediaGroup:
>>
>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>> Willmy PrintMedia GmbH: www.willmy.de
>> Willmy Consult & Content GmbH: www.willmycc.de
>> -----Ursprüngliche Nachricht-----
>> Von: TomWilcox [mailto:wilcox@hp.com]
>> Gesendet: Montag, 13. Juli 2009 12:06
>> An: fop-users@xmlgraphics.apache.org
>> Betreff: Re: AW: Area Tree Handling
>>
>>
>> Thanks Georg,
>>
>> That's great. I was doing something a bit similar however I did not
>> use the sax result to get a node of the DOM tree and traverse using
>> XPath.
>>
>> I am not sure this will be efficient enough for me as I need to
>> traverse, modify and then render various nodes repeatedly in a very
>> short space of time. I was keen to find a method that would allow me
>> to alter and reevaluate a fragment of the area tree (rerendering that
>> part of the AT using FOP without wasting time, rendering the rest).
>>
>> So I don't suppose anyone knows a way to handle, manipulate and
>> re-render a fragment of the area tree using FOP?
>>
>> I will keep experimenting in the meantime!
>>
>> Cheers,
>> Tom
>>
>>
>>
>>
>>
>> Georg Datterl wrote:
>>>
>>> Hi Tom,
>>>
>>> I get the area tree using
>>>
>>> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
>>> Transformer transformer =
>>> getMultipassFactory().newTransformer();
>>> TransformerHandler handler =
>>> getMultipassFactory().newTransformerHandler();
>>> DOMResult domResult = new DOMResult();
>>> handler.setResult(domResult);
>>>
>>> org.apache.fop.render.Renderer targetRenderer =
>>> foUserAgent.getRendererFactory().createRenderer(
>>> foUserAgent, MimeConstants.MIME_PDF);
>>>
>>> XMLRenderer renderer = new XMLRenderer();
>>> renderer.mimicRenderer(targetRenderer);
>>> renderer.setContentHandler(handler);
>>> renderer.setUserAgent(foUserAgent);
>>>
>>> foUserAgent.setRendererOverride(renderer);
>>>
>>> Fop fop =
>>> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
>>> Result res = new SAXResult(fop.getDefaultHandler());
>>> transformer.transform(source, res);
>>> org.w3c.dom.Document doc = domResult.getNode();
>>>
>>> Then I get values from the tree through Xpath
>>>
>>> XPathFactory factory=XPathFactory.newInstance();
>>> XPath xPath=factory.newXPath();
>>> NodeList nl =
>>> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
>>> XPathConstants.NODESET);
>>> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
>>> nl.item(i),
>>> XPathConstants.NUMBER)
>>>
>>> The blocks I'm interested in have well-known ids and I'm interested
>>> in more than one information below the node with id DT_TAGxx, that's
>>> why I use a nodelist. When you find a smarter way to get the
>>> information, please tell me, cause this xpath solution is not very
>>> fast in large documents...
>>>
>>> Regards,
>>>
>>> Georg Datterl
>>>
>>> ------ Kontakt ------
>>>
>>> Georg Datterl
>>>
>>> Geneon media solutions gmbh
>>> Gutenstetter Straße 8a
>>> 90449 Nürnberg
>>>
>>> HRB Nürnberg: 17193
>>> Geschäftsführer: Yong-Harry Steiert
>>>
>>> Tel.: 0911/36 78 88 - 26
>>> Fax: 0911/36 78 88 - 20
>>>
>>> www.geneon.de
>>>
>>> Weitere Mitglieder der Willmy MediaGroup:
>>>
>>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>>> Willmy PrintMedia GmbH: www.willmy.de
>>> Willmy Consult & Content GmbH: www.willmycc.de
>>> -----Ursprüngliche Nachricht-----
>>> Von: TomWilcox [mailto:wilcox@hp.com]
>>> Gesendet: Freitag, 10. Juli 2009 18:52
>>> An: fop-users@xmlgraphics.apache.org
>>> Betreff: Area Tree Handling
>>>
>>>
>>> Hi,
>>>
>>> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
>>> know about the inner workings.
>>>
>>> I have FOP 0.95 embedded in my Java application. I would like to
>>> construct an FO document and modify/examine the AreaTree for it on
>>> the fly.
>>>
>>> This is in an attempt to fill blocks (of set size and position) on a
>>> page with text/graphics and until the areatree info shows that block
>>> is full.
>>>
>>> I would like to do this as fast as possible and I thought this would
>>> imply the best route is to get hold of the areatree object in my
>>> application and modify/access the objects of interest. (Or, failing
>>> that, to get hold area tree xml fragments maybe)..
>>>
>>> Can anyone tell me how I might go about achieving this?
>>>
>>> Or even better, can anyone point me in the direction of any good
>>> tutorials/examples that show Java code using embedded FOP to
>>> generate an area tree object for an FO stream/file and then modify
>>> it with code..?
>>>
>>> That would be awesome :)
>>>
>>> Thanks in advance,
>>> Tom
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>>
>>>
>>> --------------------------------------------------------------------
>>> - 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
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24462824.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24479220.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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
Re: AW: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Thanks Georg,
That seems like the approach for me :).
However, I would like to propose a potentially useful future feature of FOP
would be the ability to do this using Java objects with a view for
optimising modifications of document fragments such as a subtree of the AT
through an API (as I think either yourself or Andreas mentioned earlier).
Any ideas where I post suggestions for FOP features?
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> In that case I'd take the interesting fo block, wrap it with a default
> page and render it. Of course the page is overhead, but other than that
> you only render the interesting block. When you are satisfied with it,
> continue with the next block. Only when all blocks are finished, combine
> them to a document. Of course, this does not work, when you have to think
> about page breaks. I have a similar problem with tables and cell content
> which has to be duplicated on the next page, if there's a break. In the
> end, I generate the whole stuff over and over again, because each table
> has to know exactly where on the page it starts. Horrible. But customer
> wants it that way, so what can I do?
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Montag, 13. Juli 2009 16:30
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: AW: Area Tree Handling
>
>
> Georg,
>
> Sorry I think I have explained this badly (or completely wrong)...
>
> I am trying to take some FO, render the AT, then look at fragments/nodes
> of the AT, then modify the FO related to that fragment and regenerate the
> AT for that fragment. Then reevaluate the AT and if my criterion are
> satisfied, I will render a PDF from the AT.
>
> What I am trying to do is take some text/image content and fill blocks of
> set size and position. At the moment I have a guess at how much space the
> text and images take up in the block and then output FO which is converted
> into a PDF. This produces page layouts with heavy over/underflow..
>
> I am constrained to use blocks of a set size and position, there I would
> like to know if I can access an intermediate format that gives me the
> amount of space left in the block and would allow me to add more
> text/images in order to fill the block.
>
> Cheers,
> Tom
>
>
> Georg Datterl wrote:
>>
>> Hi Tom,
>>
>> I'm not quite sure I understand what you want to do. You are rendering
>> FO to AT, manipulate the AT and then generate a PDF. I don't think you
>> can render the PDF, then manipulate the AT and rerender the changed
>> nodes into the previously generated PDF. You can of course generate
>> the AT, then manipulate it, then generate the PDF based on the
>> manipulated AT.
>>
>> Regards,
>>
>> Georg Datterl
>>
>> ------ Kontakt ------
>>
>> Georg Datterl
>>
>> Geneon media solutions gmbh
>> Gutenstetter Straße 8a
>> 90449 Nürnberg
>>
>> HRB Nürnberg: 17193
>> Geschäftsführer: Yong-Harry Steiert
>>
>> Tel.: 0911/36 78 88 - 26
>> Fax: 0911/36 78 88 - 20
>>
>> www.geneon.de
>>
>> Weitere Mitglieder der Willmy MediaGroup:
>>
>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>> Willmy PrintMedia GmbH: www.willmy.de
>> Willmy Consult & Content GmbH: www.willmycc.de
>> -----Ursprüngliche Nachricht-----
>> Von: TomWilcox [mailto:wilcox@hp.com]
>> Gesendet: Montag, 13. Juli 2009 12:06
>> An: fop-users@xmlgraphics.apache.org
>> Betreff: Re: AW: Area Tree Handling
>>
>>
>> Thanks Georg,
>>
>> That's great. I was doing something a bit similar however I did not
>> use the sax result to get a node of the DOM tree and traverse using
>> XPath.
>>
>> I am not sure this will be efficient enough for me as I need to
>> traverse, modify and then render various nodes repeatedly in a very
>> short space of time. I was keen to find a method that would allow me
>> to alter and reevaluate a fragment of the area tree (rerendering that
>> part of the AT using FOP without wasting time, rendering the rest).
>>
>> So I don't suppose anyone knows a way to handle, manipulate and
>> re-render a fragment of the area tree using FOP?
>>
>> I will keep experimenting in the meantime!
>>
>> Cheers,
>> Tom
>>
>>
>>
>>
>>
>> Georg Datterl wrote:
>>>
>>> Hi Tom,
>>>
>>> I get the area tree using
>>>
>>> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
>>> Transformer transformer =
>>> getMultipassFactory().newTransformer();
>>> TransformerHandler handler =
>>> getMultipassFactory().newTransformerHandler();
>>> DOMResult domResult = new DOMResult();
>>> handler.setResult(domResult);
>>>
>>> org.apache.fop.render.Renderer targetRenderer =
>>> foUserAgent.getRendererFactory().createRenderer(
>>> foUserAgent, MimeConstants.MIME_PDF);
>>>
>>> XMLRenderer renderer = new XMLRenderer();
>>> renderer.mimicRenderer(targetRenderer);
>>> renderer.setContentHandler(handler);
>>> renderer.setUserAgent(foUserAgent);
>>>
>>> foUserAgent.setRendererOverride(renderer);
>>>
>>> Fop fop =
>>> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
>>> Result res = new SAXResult(fop.getDefaultHandler());
>>> transformer.transform(source, res);
>>> org.w3c.dom.Document doc = domResult.getNode();
>>>
>>> Then I get values from the tree through Xpath
>>>
>>> XPathFactory factory=XPathFactory.newInstance();
>>> XPath xPath=factory.newXPath();
>>> NodeList nl =
>>> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
>>> XPathConstants.NODESET);
>>> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
>>> nl.item(i),
>>> XPathConstants.NUMBER)
>>>
>>> The blocks I'm interested in have well-known ids and I'm interested
>>> in more than one information below the node with id DT_TAGxx, that's
>>> why I use a nodelist. When you find a smarter way to get the
>>> information, please tell me, cause this xpath solution is not very
>>> fast in large documents...
>>>
>>> Regards,
>>>
>>> Georg Datterl
>>>
>>> ------ Kontakt ------
>>>
>>> Georg Datterl
>>>
>>> Geneon media solutions gmbh
>>> Gutenstetter Straße 8a
>>> 90449 Nürnberg
>>>
>>> HRB Nürnberg: 17193
>>> Geschäftsführer: Yong-Harry Steiert
>>>
>>> Tel.: 0911/36 78 88 - 26
>>> Fax: 0911/36 78 88 - 20
>>>
>>> www.geneon.de
>>>
>>> Weitere Mitglieder der Willmy MediaGroup:
>>>
>>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>>> Willmy PrintMedia GmbH: www.willmy.de
>>> Willmy Consult & Content GmbH: www.willmycc.de
>>> -----Ursprüngliche Nachricht-----
>>> Von: TomWilcox [mailto:wilcox@hp.com]
>>> Gesendet: Freitag, 10. Juli 2009 18:52
>>> An: fop-users@xmlgraphics.apache.org
>>> Betreff: Area Tree Handling
>>>
>>>
>>> Hi,
>>>
>>> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
>>> know about the inner workings.
>>>
>>> I have FOP 0.95 embedded in my Java application. I would like to
>>> construct an FO document and modify/examine the AreaTree for it on
>>> the fly.
>>>
>>> This is in an attempt to fill blocks (of set size and position) on a
>>> page with text/graphics and until the areatree info shows that block
>>> is full.
>>>
>>> I would like to do this as fast as possible and I thought this would
>>> imply the best route is to get hold of the areatree object in my
>>> application and modify/access the objects of interest. (Or, failing
>>> that, to get hold area tree xml fragments maybe)..
>>>
>>> Can anyone tell me how I might go about achieving this?
>>>
>>> Or even better, can anyone point me in the direction of any good
>>> tutorials/examples that show Java code using embedded FOP to generate
>>> an area tree object for an FO stream/file and then modify it with
>>> code..?
>>>
>>> That would be awesome :)
>>>
>>> Thanks in advance,
>>> Tom
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
>>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>>
>>>
>>> ---------------------------------------------------------------------
>>> 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
>>>
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24462824.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24479220.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: AW: Area Tree Handling
Posted by Georg Datterl <ge...@geneon.de>.
Hi Tom,
In that case I'd take the interesting fo block, wrap it with a default page and render it. Of course the page is overhead, but other than that you only render the interesting block. When you are satisfied with it, continue with the next block. Only when all blocks are finished, combine them to a document. Of course, this does not work, when you have to think about page breaks. I have a similar problem with tables and cell content which has to be duplicated on the next page, if there's a break. In the end, I generate the whole stuff over and over again, because each table has to know exactly where on the page it starts. Horrible. But customer wants it that way, so what can I do?
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: TomWilcox [mailto:wilcox@hp.com]
Gesendet: Montag, 13. Juli 2009 16:30
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: AW: Area Tree Handling
Georg,
Sorry I think I have explained this badly (or completely wrong)...
I am trying to take some FO, render the AT, then look at fragments/nodes of the AT, then modify the FO related to that fragment and regenerate the AT for that fragment. Then reevaluate the AT and if my criterion are satisfied, I will render a PDF from the AT.
What I am trying to do is take some text/image content and fill blocks of set size and position. At the moment I have a guess at how much space the text and images take up in the block and then output FO which is converted into a PDF. This produces page layouts with heavy over/underflow..
I am constrained to use blocks of a set size and position, there I would like to know if I can access an intermediate format that gives me the amount of space left in the block and would allow me to add more text/images in order to fill the block.
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> I'm not quite sure I understand what you want to do. You are rendering
> FO to AT, manipulate the AT and then generate a PDF. I don't think you
> can render the PDF, then manipulate the AT and rerender the changed
> nodes into the previously generated PDF. You can of course generate
> the AT, then manipulate it, then generate the PDF based on the manipulated AT.
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Montag, 13. Juli 2009 12:06
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: Area Tree Handling
>
>
> Thanks Georg,
>
> That's great. I was doing something a bit similar however I did not
> use the sax result to get a node of the DOM tree and traverse using XPath.
>
> I am not sure this will be efficient enough for me as I need to
> traverse, modify and then render various nodes repeatedly in a very
> short space of time. I was keen to find a method that would allow me
> to alter and reevaluate a fragment of the area tree (rerendering that
> part of the AT using FOP without wasting time, rendering the rest).
>
> So I don't suppose anyone knows a way to handle, manipulate and
> re-render a fragment of the area tree using FOP?
>
> I will keep experimenting in the meantime!
>
> Cheers,
> Tom
>
>
>
>
>
> Georg Datterl wrote:
>>
>> Hi Tom,
>>
>> I get the area tree using
>>
>> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
>> Transformer transformer =
>> getMultipassFactory().newTransformer();
>> TransformerHandler handler =
>> getMultipassFactory().newTransformerHandler();
>> DOMResult domResult = new DOMResult();
>> handler.setResult(domResult);
>>
>> org.apache.fop.render.Renderer targetRenderer =
>> foUserAgent.getRendererFactory().createRenderer(
>> foUserAgent, MimeConstants.MIME_PDF);
>>
>> XMLRenderer renderer = new XMLRenderer();
>> renderer.mimicRenderer(targetRenderer);
>> renderer.setContentHandler(handler);
>> renderer.setUserAgent(foUserAgent);
>>
>> foUserAgent.setRendererOverride(renderer);
>>
>> Fop fop =
>> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
>> Result res = new SAXResult(fop.getDefaultHandler());
>> transformer.transform(source, res);
>> org.w3c.dom.Document doc = domResult.getNode();
>>
>> Then I get values from the tree through Xpath
>>
>> XPathFactory factory=XPathFactory.newInstance();
>> XPath xPath=factory.newXPath();
>> NodeList nl =
>> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
>> XPathConstants.NODESET);
>> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
>> nl.item(i),
>> XPathConstants.NUMBER)
>>
>> The blocks I'm interested in have well-known ids and I'm interested
>> in more than one information below the node with id DT_TAGxx, that's
>> why I use a nodelist. When you find a smarter way to get the
>> information, please tell me, cause this xpath solution is not very
>> fast in large documents...
>>
>> Regards,
>>
>> Georg Datterl
>>
>> ------ Kontakt ------
>>
>> Georg Datterl
>>
>> Geneon media solutions gmbh
>> Gutenstetter Straße 8a
>> 90449 Nürnberg
>>
>> HRB Nürnberg: 17193
>> Geschäftsführer: Yong-Harry Steiert
>>
>> Tel.: 0911/36 78 88 - 26
>> Fax: 0911/36 78 88 - 20
>>
>> www.geneon.de
>>
>> Weitere Mitglieder der Willmy MediaGroup:
>>
>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>> Willmy PrintMedia GmbH: www.willmy.de
>> Willmy Consult & Content GmbH: www.willmycc.de
>> -----Ursprüngliche Nachricht-----
>> Von: TomWilcox [mailto:wilcox@hp.com]
>> Gesendet: Freitag, 10. Juli 2009 18:52
>> An: fop-users@xmlgraphics.apache.org
>> Betreff: Area Tree Handling
>>
>>
>> Hi,
>>
>> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
>> know about the inner workings.
>>
>> I have FOP 0.95 embedded in my Java application. I would like to
>> construct an FO document and modify/examine the AreaTree for it on
>> the fly.
>>
>> This is in an attempt to fill blocks (of set size and position) on a
>> page with text/graphics and until the areatree info shows that block
>> is full.
>>
>> I would like to do this as fast as possible and I thought this would
>> imply the best route is to get hold of the areatree object in my
>> application and modify/access the objects of interest. (Or, failing
>> that, to get hold area tree xml fragments maybe)..
>>
>> Can anyone tell me how I might go about achieving this?
>>
>> Or even better, can anyone point me in the direction of any good
>> tutorials/examples that show Java code using embedded FOP to generate
>> an area tree object for an FO stream/file and then modify it with code..?
>>
>> That would be awesome :)
>>
>> Thanks in advance,
>> Tom
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24462824.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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
Re: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Georg,
Sorry I think I have explained this badly (or completely wrong)...
I am trying to take some FO, render the AT, then look at fragments/nodes of
the AT, then modify the FO related to that fragment and regenerate the AT
for that fragment. Then reevaluate the AT and if my criterion are satisfied,
I will render a PDF from the AT.
What I am trying to do is take some text/image content and fill blocks of
set size and position. At the moment I have a guess at how much space the
text and images take up in the block and then output FO which is converted
into a PDF. This produces page layouts with heavy over/underflow..
I am constrained to use blocks of a set size and position, there I would
like to know if I can access an intermediate format that gives me the amount
of space left in the block and would allow me to add more text/images in
order to fill the block.
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> I'm not quite sure I understand what you want to do. You are rendering FO
> to AT, manipulate the AT and then generate a PDF. I don't think you can
> render the PDF, then manipulate the AT and rerender the changed nodes into
> the previously generated PDF. You can of course generate the AT, then
> manipulate it, then generate the PDF based on the manipulated AT.
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Montag, 13. Juli 2009 12:06
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: Area Tree Handling
>
>
> Thanks Georg,
>
> That's great. I was doing something a bit similar however I did not use
> the sax result to get a node of the DOM tree and traverse using XPath.
>
> I am not sure this will be efficient enough for me as I need to traverse,
> modify and then render various nodes repeatedly in a very short space of
> time. I was keen to find a method that would allow me to alter and
> reevaluate a fragment of the area tree (rerendering that part of the AT
> using FOP without wasting time, rendering the rest).
>
> So I don't suppose anyone knows a way to handle, manipulate and re-render
> a fragment of the area tree using FOP?
>
> I will keep experimenting in the meantime!
>
> Cheers,
> Tom
>
>
>
>
>
> Georg Datterl wrote:
>>
>> Hi Tom,
>>
>> I get the area tree using
>>
>> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
>> Transformer transformer =
>> getMultipassFactory().newTransformer();
>> TransformerHandler handler =
>> getMultipassFactory().newTransformerHandler();
>> DOMResult domResult = new DOMResult();
>> handler.setResult(domResult);
>>
>> org.apache.fop.render.Renderer targetRenderer =
>> foUserAgent.getRendererFactory().createRenderer(
>> foUserAgent, MimeConstants.MIME_PDF);
>>
>> XMLRenderer renderer = new XMLRenderer();
>> renderer.mimicRenderer(targetRenderer);
>> renderer.setContentHandler(handler);
>> renderer.setUserAgent(foUserAgent);
>>
>> foUserAgent.setRendererOverride(renderer);
>>
>> Fop fop =
>> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
>> Result res = new SAXResult(fop.getDefaultHandler());
>> transformer.transform(source, res);
>> org.w3c.dom.Document doc = domResult.getNode();
>>
>> Then I get values from the tree through Xpath
>>
>> XPathFactory factory=XPathFactory.newInstance();
>> XPath xPath=factory.newXPath();
>> NodeList nl =
>> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
>> XPathConstants.NODESET);
>> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
>> nl.item(i),
>> XPathConstants.NUMBER)
>>
>> The blocks I'm interested in have well-known ids and I'm interested in
>> more than one information below the node with id DT_TAGxx, that's why
>> I use a nodelist. When you find a smarter way to get the information,
>> please tell me, cause this xpath solution is not very fast in large
>> documents...
>>
>> Regards,
>>
>> Georg Datterl
>>
>> ------ Kontakt ------
>>
>> Georg Datterl
>>
>> Geneon media solutions gmbh
>> Gutenstetter Straße 8a
>> 90449 Nürnberg
>>
>> HRB Nürnberg: 17193
>> Geschäftsführer: Yong-Harry Steiert
>>
>> Tel.: 0911/36 78 88 - 26
>> Fax: 0911/36 78 88 - 20
>>
>> www.geneon.de
>>
>> Weitere Mitglieder der Willmy MediaGroup:
>>
>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>> Willmy PrintMedia GmbH: www.willmy.de
>> Willmy Consult & Content GmbH: www.willmycc.de
>> -----Ursprüngliche Nachricht-----
>> Von: TomWilcox [mailto:wilcox@hp.com]
>> Gesendet: Freitag, 10. Juli 2009 18:52
>> An: fop-users@xmlgraphics.apache.org
>> Betreff: Area Tree Handling
>>
>>
>> Hi,
>>
>> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
>> know about the inner workings.
>>
>> I have FOP 0.95 embedded in my Java application. I would like to
>> construct an FO document and modify/examine the AreaTree for it on the
>> fly.
>>
>> This is in an attempt to fill blocks (of set size and position) on a
>> page with text/graphics and until the areatree info shows that block is
>> full.
>>
>> I would like to do this as fast as possible and I thought this would
>> imply the best route is to get hold of the areatree object in my
>> application and modify/access the objects of interest. (Or, failing
>> that, to get hold area tree xml fragments maybe)..
>>
>> Can anyone tell me how I might go about achieving this?
>>
>> Or even better, can anyone point me in the direction of any good
>> tutorials/examples that show Java code using embedded FOP to generate
>> an area tree object for an FO stream/file and then modify it with code..?
>>
>> That would be awesome :)
>>
>> Thanks in advance,
>> Tom
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24462824.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: Area Tree Handling
Posted by Georg Datterl <ge...@geneon.de>.
Hi Tom,
I'm not quite sure I understand what you want to do. You are rendering FO to AT, manipulate the AT and then generate a PDF. I don't think you can render the PDF, then manipulate the AT and rerender the changed nodes into the previously generated PDF. You can of course generate the AT, then manipulate it, then generate the PDF based on the manipulated AT.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: TomWilcox [mailto:wilcox@hp.com]
Gesendet: Montag, 13. Juli 2009 12:06
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: Area Tree Handling
Thanks Georg,
That's great. I was doing something a bit similar however I did not use the sax result to get a node of the DOM tree and traverse using XPath.
I am not sure this will be efficient enough for me as I need to traverse, modify and then render various nodes repeatedly in a very short space of time. I was keen to find a method that would allow me to alter and reevaluate a fragment of the area tree (rerendering that part of the AT using FOP without wasting time, rendering the rest).
So I don't suppose anyone knows a way to handle, manipulate and re-render a fragment of the area tree using FOP?
I will keep experimenting in the meantime!
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> I get the area tree using
>
> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
> Transformer transformer =
> getMultipassFactory().newTransformer();
> TransformerHandler handler =
> getMultipassFactory().newTransformerHandler();
> DOMResult domResult = new DOMResult();
> handler.setResult(domResult);
>
> org.apache.fop.render.Renderer targetRenderer =
> foUserAgent.getRendererFactory().createRenderer(
> foUserAgent, MimeConstants.MIME_PDF);
>
> XMLRenderer renderer = new XMLRenderer();
> renderer.mimicRenderer(targetRenderer);
> renderer.setContentHandler(handler);
> renderer.setUserAgent(foUserAgent);
>
> foUserAgent.setRendererOverride(renderer);
>
> Fop fop =
> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
> Result res = new SAXResult(fop.getDefaultHandler());
> transformer.transform(source, res);
> org.w3c.dom.Document doc = domResult.getNode();
>
> Then I get values from the tree through Xpath
>
> XPathFactory factory=XPathFactory.newInstance();
> XPath xPath=factory.newXPath();
> NodeList nl =
> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
> XPathConstants.NODESET);
> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
> nl.item(i),
> XPathConstants.NUMBER)
>
> The blocks I'm interested in have well-known ids and I'm interested in
> more than one information below the node with id DT_TAGxx, that's why
> I use a nodelist. When you find a smarter way to get the information,
> please tell me, cause this xpath solution is not very fast in large documents...
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Freitag, 10. Juli 2009 18:52
> An: fop-users@xmlgraphics.apache.org
> Betreff: Area Tree Handling
>
>
> Hi,
>
> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
> know about the inner workings.
>
> I have FOP 0.95 embedded in my Java application. I would like to
> construct an FO document and modify/examine the AreaTree for it on the fly.
>
> This is in an attempt to fill blocks (of set size and position) on a
> page with text/graphics and until the areatree info shows that block is full.
>
> I would like to do this as fast as possible and I thought this would
> imply the best route is to get hold of the areatree object in my
> application and modify/access the objects of interest. (Or, failing
> that, to get hold area tree xml fragments maybe)..
>
> Can anyone tell me how I might go about achieving this?
>
> Or even better, can anyone point me in the direction of any good
> tutorials/examples that show Java code using embedded FOP to generate
> an area tree object for an FO stream/file and then modify it with code..?
>
> That would be awesome :)
>
> Thanks in advance,
> Tom
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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
Re: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Thanks Georg,
That's great. I was doing something a bit similar however I did not use the
sax result to get a node of the DOM tree and traverse using XPath.
I am not sure this will be efficient enough for me as I need to traverse,
modify and then render various nodes repeatedly in a very short space of
time. I was keen to find a method that would allow me to alter and
reevaluate a fragment of the area tree (rerendering that part of the AT
using FOP without wasting time, rendering the rest).
So I don't suppose anyone knows a way to handle, manipulate and re-render a
fragment of the area tree using FOP?
I will keep experimenting in the meantime!
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> I get the area tree using
>
> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
> Transformer transformer =
> getMultipassFactory().newTransformer();
> TransformerHandler handler =
> getMultipassFactory().newTransformerHandler();
> DOMResult domResult = new DOMResult();
> handler.setResult(domResult);
>
> org.apache.fop.render.Renderer targetRenderer =
> foUserAgent.getRendererFactory().createRenderer(
> foUserAgent, MimeConstants.MIME_PDF);
>
> XMLRenderer renderer = new XMLRenderer();
> renderer.mimicRenderer(targetRenderer);
> renderer.setContentHandler(handler);
> renderer.setUserAgent(foUserAgent);
>
> foUserAgent.setRendererOverride(renderer);
>
> Fop fop =
> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
> Result res = new SAXResult(fop.getDefaultHandler());
> transformer.transform(source, res);
> org.w3c.dom.Document doc = domResult.getNode();
>
> Then I get values from the tree through Xpath
>
> XPathFactory factory=XPathFactory.newInstance();
> XPath xPath=factory.newXPath();
> NodeList nl =
> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
> XPathConstants.NODESET);
> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd", nl.item(i),
> XPathConstants.NUMBER)
>
> The blocks I'm interested in have well-known ids and I'm interested in
> more than one information below the node with id DT_TAGxx, that's why I
> use a nodelist. When you find a smarter way to get the information, please
> tell me, cause this xpath solution is not very fast in large documents...
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Freitag, 10. Juli 2009 18:52
> An: fop-users@xmlgraphics.apache.org
> Betreff: Area Tree Handling
>
>
> Hi,
>
> First of all, I am a FOP dummy. I can make PDFs from FO but I don't know
> about the inner workings.
>
> I have FOP 0.95 embedded in my Java application. I would like to construct
> an FO document and modify/examine the AreaTree for it on the fly.
>
> This is in an attempt to fill blocks (of set size and position) on a page
> with text/graphics and until the areatree info shows that block is full.
>
> I would like to do this as fast as possible and I thought this would imply
> the best route is to get hold of the areatree object in my application and
> modify/access the objects of interest. (Or, failing that, to get hold area
> tree xml fragments maybe)..
>
> Can anyone tell me how I might go about achieving this?
>
> Or even better, can anyone point me in the direction of any good
> tutorials/examples that show Java code using embedded FOP to generate an
> area tree object for an FO stream/file and then modify it with code..?
>
> That would be awesome :)
>
> Thanks in advance,
> Tom
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24458974.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: Area Tree Handling
Posted by Jeremias Maerki <de...@jeremias-maerki.ch>.
That's Georg's invention and not part of FOP.
On 26.08.2009 21:57:41 TomWilcox wrote:
>
> Hi Georg,
>
> I was just having another look at this and I realised something I hadn't
> recognised before...
>
> I have not come across a "multipass" factory during my FOP experiments.
> Could you possibly explain the getMultipassFactory() method to me..?
>
> Apologies if this is a very ignorant question.
>
> Cheers,
> Tom
>
>
>
>
>
> Georg Datterl wrote:
> >
> > Hi Tom,
> >
> > I get the area tree using
> >
> > FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
> > Transformer transformer =
> > getMultipassFactory().newTransformer();
> > TransformerHandler handler =
> > getMultipassFactory().newTransformerHandler();
> > DOMResult domResult = new DOMResult();
> > handler.setResult(domResult);
> >
> > org.apache.fop.render.Renderer targetRenderer =
> > foUserAgent.getRendererFactory().createRenderer(
> > foUserAgent, MimeConstants.MIME_PDF);
> >
> > XMLRenderer renderer = new XMLRenderer();
> > renderer.mimicRenderer(targetRenderer);
> > renderer.setContentHandler(handler);
> > renderer.setUserAgent(foUserAgent);
> >
> > foUserAgent.setRendererOverride(renderer);
> >
> > Fop fop =
> > getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
> > Result res = new SAXResult(fop.getDefaultHandler());
> > transformer.transform(source, res);
> > org.w3c.dom.Document doc = domResult.getNode();
> >
> > Then I get values from the tree through Xpath
> >
> > XPathFactory factory=XPathFactory.newInstance();
> > XPath xPath=factory.newXPath();
> > NodeList nl =
> > (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
> > XPathConstants.NODESET);
> > xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd", nl.item(i),
> > XPathConstants.NUMBER)
> >
> > The blocks I'm interested in have well-known ids and I'm interested in
> > more than one information below the node with id DT_TAGxx, that's why I
> > use a nodelist. When you find a smarter way to get the information, please
> > tell me, cause this xpath solution is not very fast in large documents...
> >
> > Regards,
> >
> > Georg Datterl
> >
> > ------ Kontakt ------
> >
> > Georg Datterl
> >
> > Geneon media solutions gmbh
> > Gutenstetter Straße 8a
> > 90449 Nürnberg
> >
> > HRB Nürnberg: 17193
> > Geschäftsführer: Yong-Harry Steiert
> >
> > Tel.: 0911/36 78 88 - 26
> > Fax: 0911/36 78 88 - 20
> >
> > www.geneon.de
> >
> > Weitere Mitglieder der Willmy MediaGroup:
> >
> > IRS Integrated Realization Services GmbH: www.irs-nbg.de
> > Willmy PrintMedia GmbH: www.willmy.de
> > Willmy Consult & Content GmbH: www.willmycc.de
> > -----Ursprüngliche Nachricht-----
> > Von: TomWilcox [mailto:wilcox@hp.com]
> > Gesendet: Freitag, 10. Juli 2009 18:52
> > An: fop-users@xmlgraphics.apache.org
> > Betreff: Area Tree Handling
> >
> >
> > Hi,
> >
> > First of all, I am a FOP dummy. I can make PDFs from FO but I don't know
> > about the inner workings.
> >
> > I have FOP 0.95 embedded in my Java application. I would like to construct
> > an FO document and modify/examine the AreaTree for it on the fly.
> >
> > This is in an attempt to fill blocks (of set size and position) on a page
> > with text/graphics and until the areatree info shows that block is full.
> >
> > I would like to do this as fast as possible and I thought this would imply
> > the best route is to get hold of the areatree object in my application and
> > modify/access the objects of interest. (Or, failing that, to get hold area
> > tree xml fragments maybe)..
> >
> > Can anyone tell me how I might go about achieving this?
> >
> > Or even better, can anyone point me in the direction of any good
> > tutorials/examples that show Java code using embedded FOP to generate an
> > area tree object for an FO stream/file and then modify it with code..?
> >
> > That would be awesome :)
> >
> > Thanks in advance,
> > Tom
> > --
> > View this message in context:
> > http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
> > Sent from the FOP - Users mailing list archive at Nabble.com.
> >
> >
> > ---------------------------------------------------------------------
> > 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
> >
> >
> >
>
> --
> View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25156283.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
Jeremias Maerki
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
Re: AW: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
OK. Thanks for the clarification.
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> getMultipassFactory() is just a factory method which returns
> SAXTransformerFactory.newInstance(); As Jeremias said, not FOP.
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Mittwoch, 26. August 2009 21:58
> An: fop-users@xmlgraphics.apache.org
> Betreff: Re: AW: Area Tree Handling
>
>
> Hi Georg,
>
> I was just having another look at this and I realised something I hadn't
> recognised before...
>
> I have not come across a "multipass" factory during my FOP experiments.
> Could you possibly explain the getMultipassFactory() method to me..?
>
> Apologies if this is a very ignorant question.
>
> Cheers,
> Tom
>
>
>
>
>
> Georg Datterl wrote:
>>
>> Hi Tom,
>>
>> I get the area tree using
>>
>> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
>> Transformer transformer =
>> getMultipassFactory().newTransformer();
>> TransformerHandler handler =
>> getMultipassFactory().newTransformerHandler();
>> DOMResult domResult = new DOMResult();
>> handler.setResult(domResult);
>>
>> org.apache.fop.render.Renderer targetRenderer =
>> foUserAgent.getRendererFactory().createRenderer(
>> foUserAgent, MimeConstants.MIME_PDF);
>>
>> XMLRenderer renderer = new XMLRenderer();
>> renderer.mimicRenderer(targetRenderer);
>> renderer.setContentHandler(handler);
>> renderer.setUserAgent(foUserAgent);
>>
>> foUserAgent.setRendererOverride(renderer);
>>
>> Fop fop =
>> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
>> Result res = new SAXResult(fop.getDefaultHandler());
>> transformer.transform(source, res);
>> org.w3c.dom.Document doc = domResult.getNode();
>>
>> Then I get values from the tree through Xpath
>>
>> XPathFactory factory=XPathFactory.newInstance();
>> XPath xPath=factory.newXPath();
>> NodeList nl =
>> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
>> XPathConstants.NODESET);
>> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
>> nl.item(i),
>> XPathConstants.NUMBER)
>>
>> The blocks I'm interested in have well-known ids and I'm interested in
>> more than one information below the node with id DT_TAGxx, that's why
>> I use a nodelist. When you find a smarter way to get the information,
>> please tell me, cause this xpath solution is not very fast in large
>> documents...
>>
>> Regards,
>>
>> Georg Datterl
>>
>> ------ Kontakt ------
>>
>> Georg Datterl
>>
>> Geneon media solutions gmbh
>> Gutenstetter Straße 8a
>> 90449 Nürnberg
>>
>> HRB Nürnberg: 17193
>> Geschäftsführer: Yong-Harry Steiert
>>
>> Tel.: 0911/36 78 88 - 26
>> Fax: 0911/36 78 88 - 20
>>
>> www.geneon.de
>>
>> Weitere Mitglieder der Willmy MediaGroup:
>>
>> IRS Integrated Realization Services GmbH: www.irs-nbg.de
>> Willmy PrintMedia GmbH: www.willmy.de
>> Willmy Consult & Content GmbH: www.willmycc.de
>> -----Ursprüngliche Nachricht-----
>> Von: TomWilcox [mailto:wilcox@hp.com]
>> Gesendet: Freitag, 10. Juli 2009 18:52
>> An: fop-users@xmlgraphics.apache.org
>> Betreff: Area Tree Handling
>>
>>
>> Hi,
>>
>> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
>> know about the inner workings.
>>
>> I have FOP 0.95 embedded in my Java application. I would like to
>> construct an FO document and modify/examine the AreaTree for it on the
>> fly.
>>
>> This is in an attempt to fill blocks (of set size and position) on a
>> page with text/graphics and until the areatree info shows that block is
>> full.
>>
>> I would like to do this as fast as possible and I thought this would
>> imply the best route is to get hold of the areatree object in my
>> application and modify/access the objects of interest. (Or, failing
>> that, to get hold area tree xml fragments maybe)..
>>
>> Can anyone tell me how I might go about achieving this?
>>
>> Or even better, can anyone point me in the direction of any good
>> tutorials/examples that show Java code using embedded FOP to generate
>> an area tree object for an FO stream/file and then modify it with code..?
>>
>> That would be awesome :)
>>
>> Thanks in advance,
>> Tom
>> --
>> View this message in context:
>> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
>> Sent from the FOP - Users mailing list archive at Nabble.com.
>>
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>>
>
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p25156283.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25197058.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: AW: Area Tree Handling
Posted by Georg Datterl <ge...@geneon.de>.
Hi Tom,
getMultipassFactory() is just a factory method which returns SAXTransformerFactory.newInstance(); As Jeremias said, not FOP.
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: TomWilcox [mailto:wilcox@hp.com]
Gesendet: Mittwoch, 26. August 2009 21:58
An: fop-users@xmlgraphics.apache.org
Betreff: Re: AW: Area Tree Handling
Hi Georg,
I was just having another look at this and I realised something I hadn't recognised before...
I have not come across a "multipass" factory during my FOP experiments.
Could you possibly explain the getMultipassFactory() method to me..?
Apologies if this is a very ignorant question.
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> I get the area tree using
>
> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
> Transformer transformer =
> getMultipassFactory().newTransformer();
> TransformerHandler handler =
> getMultipassFactory().newTransformerHandler();
> DOMResult domResult = new DOMResult();
> handler.setResult(domResult);
>
> org.apache.fop.render.Renderer targetRenderer =
> foUserAgent.getRendererFactory().createRenderer(
> foUserAgent, MimeConstants.MIME_PDF);
>
> XMLRenderer renderer = new XMLRenderer();
> renderer.mimicRenderer(targetRenderer);
> renderer.setContentHandler(handler);
> renderer.setUserAgent(foUserAgent);
>
> foUserAgent.setRendererOverride(renderer);
>
> Fop fop =
> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
> Result res = new SAXResult(fop.getDefaultHandler());
> transformer.transform(source, res);
> org.w3c.dom.Document doc = domResult.getNode();
>
> Then I get values from the tree through Xpath
>
> XPathFactory factory=XPathFactory.newInstance();
> XPath xPath=factory.newXPath();
> NodeList nl =
> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
> XPathConstants.NODESET);
> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd",
> nl.item(i),
> XPathConstants.NUMBER)
>
> The blocks I'm interested in have well-known ids and I'm interested in
> more than one information below the node with id DT_TAGxx, that's why
> I use a nodelist. When you find a smarter way to get the information,
> please tell me, cause this xpath solution is not very fast in large documents...
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Freitag, 10. Juli 2009 18:52
> An: fop-users@xmlgraphics.apache.org
> Betreff: Area Tree Handling
>
>
> Hi,
>
> First of all, I am a FOP dummy. I can make PDFs from FO but I don't
> know about the inner workings.
>
> I have FOP 0.95 embedded in my Java application. I would like to
> construct an FO document and modify/examine the AreaTree for it on the fly.
>
> This is in an attempt to fill blocks (of set size and position) on a
> page with text/graphics and until the areatree info shows that block is full.
>
> I would like to do this as fast as possible and I thought this would
> imply the best route is to get hold of the areatree object in my
> application and modify/access the objects of interest. (Or, failing
> that, to get hold area tree xml fragments maybe)..
>
> Can anyone tell me how I might go about achieving this?
>
> Or even better, can anyone point me in the direction of any good
> tutorials/examples that show Java code using embedded FOP to generate
> an area tree object for an FO stream/file and then modify it with code..?
>
> That would be awesome :)
>
> Thanks in advance,
> Tom
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25156283.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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
Re: AW: Area Tree Handling
Posted by TomWilcox <wi...@hp.com>.
Hi Georg,
I was just having another look at this and I realised something I hadn't
recognised before...
I have not come across a "multipass" factory during my FOP experiments.
Could you possibly explain the getMultipassFactory() method to me..?
Apologies if this is a very ignorant question.
Cheers,
Tom
Georg Datterl wrote:
>
> Hi Tom,
>
> I get the area tree using
>
> FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
> Transformer transformer =
> getMultipassFactory().newTransformer();
> TransformerHandler handler =
> getMultipassFactory().newTransformerHandler();
> DOMResult domResult = new DOMResult();
> handler.setResult(domResult);
>
> org.apache.fop.render.Renderer targetRenderer =
> foUserAgent.getRendererFactory().createRenderer(
> foUserAgent, MimeConstants.MIME_PDF);
>
> XMLRenderer renderer = new XMLRenderer();
> renderer.mimicRenderer(targetRenderer);
> renderer.setContentHandler(handler);
> renderer.setUserAgent(foUserAgent);
>
> foUserAgent.setRendererOverride(renderer);
>
> Fop fop =
> getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
> Result res = new SAXResult(fop.getDefaultHandler());
> transformer.transform(source, res);
> org.w3c.dom.Document doc = domResult.getNode();
>
> Then I get values from the tree through Xpath
>
> XPathFactory factory=XPathFactory.newInstance();
> XPath xPath=factory.newXPath();
> NodeList nl =
> (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc,
> XPathConstants.NODESET);
> xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd", nl.item(i),
> XPathConstants.NUMBER)
>
> The blocks I'm interested in have well-known ids and I'm interested in
> more than one information below the node with id DT_TAGxx, that's why I
> use a nodelist. When you find a smarter way to get the information, please
> tell me, cause this xpath solution is not very fast in large documents...
>
> Regards,
>
> Georg Datterl
>
> ------ Kontakt ------
>
> Georg Datterl
>
> Geneon media solutions gmbh
> Gutenstetter Straße 8a
> 90449 Nürnberg
>
> HRB Nürnberg: 17193
> Geschäftsführer: Yong-Harry Steiert
>
> Tel.: 0911/36 78 88 - 26
> Fax: 0911/36 78 88 - 20
>
> www.geneon.de
>
> Weitere Mitglieder der Willmy MediaGroup:
>
> IRS Integrated Realization Services GmbH: www.irs-nbg.de
> Willmy PrintMedia GmbH: www.willmy.de
> Willmy Consult & Content GmbH: www.willmycc.de
> -----Ursprüngliche Nachricht-----
> Von: TomWilcox [mailto:wilcox@hp.com]
> Gesendet: Freitag, 10. Juli 2009 18:52
> An: fop-users@xmlgraphics.apache.org
> Betreff: Area Tree Handling
>
>
> Hi,
>
> First of all, I am a FOP dummy. I can make PDFs from FO but I don't know
> about the inner workings.
>
> I have FOP 0.95 embedded in my Java application. I would like to construct
> an FO document and modify/examine the AreaTree for it on the fly.
>
> This is in an attempt to fill blocks (of set size and position) on a page
> with text/graphics and until the areatree info shows that block is full.
>
> I would like to do this as fast as possible and I thought this would imply
> the best route is to get hold of the areatree object in my application and
> modify/access the objects of interest. (Or, failing that, to get hold area
> tree xml fragments maybe)..
>
> Can anyone tell me how I might go about achieving this?
>
> Or even better, can anyone point me in the direction of any good
> tutorials/examples that show Java code using embedded FOP to generate an
> area tree object for an FO stream/file and then modify it with code..?
>
> That would be awesome :)
>
> Thanks in advance,
> Tom
> --
> View this message in context:
> http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
> Sent from the FOP - Users mailing list archive at Nabble.com.
>
>
> ---------------------------------------------------------------------
> 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
>
>
>
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p25156283.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
To unsubscribe, e-mail: fop-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: fop-users-help@xmlgraphics.apache.org
AW: Area Tree Handling
Posted by Georg Datterl <ge...@geneon.de>.
Hi Tom,
I get the area tree using
FOUserAgent foUserAgent = getFopFactory().newFOUserAgent();
Transformer transformer = getMultipassFactory().newTransformer();
TransformerHandler handler = getMultipassFactory().newTransformerHandler();
DOMResult domResult = new DOMResult();
handler.setResult(domResult);
org.apache.fop.render.Renderer targetRenderer =
foUserAgent.getRendererFactory().createRenderer(
foUserAgent, MimeConstants.MIME_PDF);
XMLRenderer renderer = new XMLRenderer();
renderer.mimicRenderer(targetRenderer);
renderer.setContentHandler(handler);
renderer.setUserAgent(foUserAgent);
foUserAgent.setRendererOverride(renderer);
Fop fop = getFopFactory().newFop(MimeConstants.MIME_FOP_AREA_TREE, foUserAgent);
Result res = new SAXResult(fop.getDefaultHandler());
transformer.transform(source, res);
org.w3c.dom.Document doc = domResult.getNode();
Then I get values from the tree through Xpath
XPathFactory factory=XPathFactory.newInstance();
XPath xPath=factory.newXPath();
NodeList nl = (NodeList)xPath.evaluate("//block[@prod-id='"+DT_TAG+id+"']", doc, XPathConstants.NODESET);
xPath.evaluate(".//block[@prod-id='"+L1_TAG+id+"']/@bpd", nl.item(i), XPathConstants.NUMBER)
The blocks I'm interested in have well-known ids and I'm interested in more than one information below the node with id DT_TAGxx, that's why I use a nodelist. When you find a smarter way to get the information, please tell me, cause this xpath solution is not very fast in large documents...
Regards,
Georg Datterl
------ Kontakt ------
Georg Datterl
Geneon media solutions gmbh
Gutenstetter Straße 8a
90449 Nürnberg
HRB Nürnberg: 17193
Geschäftsführer: Yong-Harry Steiert
Tel.: 0911/36 78 88 - 26
Fax: 0911/36 78 88 - 20
www.geneon.de
Weitere Mitglieder der Willmy MediaGroup:
IRS Integrated Realization Services GmbH: www.irs-nbg.de
Willmy PrintMedia GmbH: www.willmy.de
Willmy Consult & Content GmbH: www.willmycc.de
-----Ursprüngliche Nachricht-----
Von: TomWilcox [mailto:wilcox@hp.com]
Gesendet: Freitag, 10. Juli 2009 18:52
An: fop-users@xmlgraphics.apache.org
Betreff: Area Tree Handling
Hi,
First of all, I am a FOP dummy. I can make PDFs from FO but I don't know about the inner workings.
I have FOP 0.95 embedded in my Java application. I would like to construct an FO document and modify/examine the AreaTree for it on the fly.
This is in an attempt to fill blocks (of set size and position) on a page with text/graphics and until the areatree info shows that block is full.
I would like to do this as fast as possible and I thought this would imply the best route is to get hold of the areatree object in my application and modify/access the objects of interest. (Or, failing that, to get hold area tree xml fragments maybe)..
Can anyone tell me how I might go about achieving this?
Or even better, can anyone point me in the direction of any good tutorials/examples that show Java code using embedded FOP to generate an area tree object for an FO stream/file and then modify it with code..?
That would be awesome :)
Thanks in advance,
Tom
--
View this message in context: http://www.nabble.com/Area-Tree-Handling-tp24431098p24431098.html
Sent from the FOP - Users mailing list archive at Nabble.com.
---------------------------------------------------------------------
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