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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: AW: AW: AW: AW: AW: Area Tree Handling
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:wil...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@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-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: AW: AW: AW: Area Tree Handling
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:wil...@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:wil...@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
Re: AW: AW: AW: AW: Area Tree Handling
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:wil...@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:wil...@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
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: mandr...@jabber.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
AW: AW: AW: AW: AW: Area Tree Handling
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.delme...@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: mandr...@jabber.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
Re: AW: AW: AW: AW: AW: Area Tree Handling
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: mandr...@jabber.org - To unsubscribe, e-mail: fop-users-unsubscr...@xmlgraphics.apache.org For additional commands, e-mail: fop-users-h...@xmlgraphics.apache.org
