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:[email protected]] > Gesendet: Montag, 13. Juli 2009 16:30 > An: [email protected] > 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:[email protected]] >> Gesendet: Montag, 13. Juli 2009 12:06 >> An: [email protected] >> 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("//blo...@prod-id='"+DT_TAG+id+"']", doc, >>> XPathConstants.NODESET); >>> xPath.evaluate(".//blo...@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:[email protected]] >>> Gesendet: Freitag, 10. Juli 2009 18:52 >>> An: [email protected] >>> 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: [email protected] >>> For additional commands, e-mail: >>> [email protected] >>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [email protected] >>> For additional commands, e-mail: >>> [email protected] >>> >>> >>> >> >> -- >> 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: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: [email protected] >> For additional commands, e-mail: [email protected] >> >> >> > > -- > 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: [email protected] > For additional commands, e-mail: [email protected] > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > > -- 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: [email protected] For additional commands, e-mail: [email protected]
